1. Field of the Invention
This invention relates generally to the field of computer networking, and in particular to protecting the integrity of data packets processed by performance-enhancing proxies (PEPs) in a networking environment.
2. Background of the Invention
One of the most widely used computer networking protocols is the Internet Protocol (IP). IP is a connectionless, best-effort, unreliable, routable networking protocol. Applications that require reliable communications typically use the Transmission Control Protocol (TCP) on top of IP. The TCP protocol layer provides flow control, packet loss detection, lost packet retransmission, congestion avoidance, and other features to provide reliable communications over the unreliable IP networking substrate. Used together, these networking protocols are commonly referred to as TCP/IP. Detailed descriptions of TCP and IP are found in RFC 792 and RFC 793.
TCP has a variety of known limitations that impair its performance, both in general and under restricted circumstances. Because of the importance of TCP networking, many approaches have been tried for mitigating, eliminating, or bypassing its limitations. These approaches include the total abandonment of TCP in favor of a new protocol, the use of nonstandard enhancements to TCP over all or part of the network path, and the use of standardized enhancements. But deploying such enhancements, even standardized ones, can be difficult. Much of the equipment currently used on networks is old enough that it does not support some of the most important standardized enhancements, and of course non-standard ones are generally not supported at all.
In many cases, however, it is possible to give existing “legacy” equipment the benefits of newer technology through the use of a performance enhancing proxy (PEP). PEPs includes devices that manipulate the protocol, data, or both of a data stream in a way that increases performance while concealing these manipulations from the network equipment at the endpoints. For example, compressing the TCP data stream (payload) can reduce the size of the data to one-half or less of its original size, doubling the effective bandwidth. Compression is only appropriate on low bandwidth links, however, since on fast links the CPU burden of compression erases its performance advantages. Because a characteristic of IP networking is that the end nodes are not aware of the network topology or the speed of the various links, compression and decompression should be implemented not by the end nodes but by hardware attached to the slow links themselves (e.g., at the LAN/WAN boundary). This allows the compression feature to be deployed transparently and where it is needed, with no requirement for universal upgrades of end nodes. This is just one example, however, as many types of PEPs and PEP algorithms are known. RFC 3135 includes a detailed discussion of some of the better-known PEPs.
In some circumstances, PEPs can fail in such a way that the flow of packets through the network is not interrupted. This can happen, for example, when the packets flow around a disabled PEP in some way. Moreover, even if the PEP does not actually fail, similar problems can occur because routing changes can cause packets to bypass a PEP.
Existing networks are designed on the presumption that certain kinds of traffic will take place and other kinds will not. Security considerations often lead to the installation of elaborate firewalls to prevent anomalous traffic from being allowed into or out of a site. But to older equipment, new packet behavior may be considered anomalous. For this reason, a new and innovative transport protocol will most likely fail to interoperate with existing network equipment without a great deal of effort spent towards tedious reconfiguration.
Quality of service (QoS) considerations cause similar problems. For example, an organization may decide that all of its mission-critical traffic is done over TCP, and that high-volume UDP traffic (e.g., streaming music) is mostly irrelevant to the company—when it happens at all. This organization may thus give UDP traffic a low priority. If the organization then installs PEPs that attempt to bypass TCP performance limitations through the translation of TCP streams to UDP, performance would likely plummet rather than increase. This is true not only of UDP, but likely of any protocol not currently in wide use at the organization. Furthermore, the gateways on the interior of the wide-area network, controlled by service providers rather than the organization itself, may be tuned similarly.
Accordingly, the reliable map through the security and QoS minefields involves following in the footsteps of a transport that already passes through the network unscathed. As a rule of thumb, to be confident that data will reach its destination tomorrow is to make the traffic seem indistinguishable from how it operates today. This means using not only the same transport mechanism (e.g., TCP) used by the original application, but also the same host and port numbers.
But traditional methods of enhancing network application encapsulate the original data in a new form, with an entirely new IP header, and often switch away from TCP. This can cause problems with performance and connectivity. Firewalls and QoS software are often the most mysterious and poorly understood elements of a network, and a product that requires significant reconfiguration of them is likely to fail. However, if the original data packets are not encapsulated, the problem remains for the data receiver to distinguish between standard, unmodified packets and those that have passed through a PEP. The results of making such a mistake (e.g., assuming a data packet has been processed by a PEP when it has not, or visa versa) could be catastrophic.
This problem is illustrated for example in the data compression context. In this example, two sites in a network connection have identical PEPs that perform transparent TCP payload compression and decompression, without modifying the host or port numbers. This modified packet stream passes through any set of routers, firewalls, gateways, and QoS units that the original packet stream would. However, if a change were made the network routing and the receiving PEP were bypassed, the ultimate receiver would see a compressed data stream when it expected an uncompressed stream. Importantly, there would be no indication that the data are compressed, leading to data corruption. Similarly, the same problem could occur if the receiving unit failed in some way.